home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Grab Bag
/
Shareware Grab Bag.iso
/
081
/
opus100b.arc
/
OMMMDOCS.ARC
/
OMMM.DOC
< prev
Wrap
Text File
|
1987-04-18
|
48KB
|
1,067 lines
########### ############ #### #### ############
############# ############# ## ## ############
### ### ## ### ## ## ## #
## ## ## ## ## ## ##
## ## ## ### ## ## ###
## ## ############# ## ## ##########
## ## ############ ## ## ###########
## ## ## ## ## ###
## ## ## ## ## ##
## ## ## ## ## ##
### ### ## ### ### # ##
############# ## ############## ############
########### #### ############ ###########
########### ## ## ## ## ## ##
############# ### ### ### ### ### ###
### ### #### #### #### #### #### ####
## ## ## ## ## ## ## ## ## ## ## ## ## ##
## ## ## # ## ## # ## ## # ##
## ## ## ## ## ## ## ##
## ## ## ## ## ## ## ##
## ## ## ## ## ## ## ##
## ## ## ## ## ## ## ##
## ## ## ## ## ## ## ##
### ### ## ## ## ## ## ##
############# ## ## ## ## ## ##
########### #### #### #### #### #### ####
+--------------------------------------------------------+
| THE MATRIX: |
| The world's first CyberPunk BBS Network |
+--------------------------------------------------------+
Technical Reference Document
----------------------------
NAVIGATING THE MATRIX
using
oMMM: The Opus Matrix Message Masher
THIS IS A TEST COPY: NOT FOR DISTRIBUTION
-----------------------------------------
The POLE's OPUS Computer Conversation System
(c)Copyright, 1987; Wynn Wagner III; All Rights Reserved
9 April 1987
Low-Budget Table of Contents
----------------------------
Section
Number Title Page
-------------------------------------------------------------------
1........Upfront....................................following this
2........Outbound Holding Area......................after section 1
3........Methods....................................after section 2
4........What's in the holding area.................after "Methods"
5........Simple oMMM................................after section 4
6........The indirect approach......................after section 5
7........The control file...........................after section 6
8........Using oMMM.................................after section 7
9........What about Opus?...........................after section 7
10........CyberPunk?.................................at the very end
Original oMMM (now a collectors item) was written by Wynn Wagner III,
otherwise known as "Arrogant Hacker I"
The program was tweaked/rewritten/cleaned-up/added-to under the
care of Bob Hartman, otherwise known as "Arrogant Hacker II"
+-----------------------------------------------+
| |
| "Hackers - Heroes of the Computer Revolution" |
| The story of the whiz kids whose irreverence, |
| idealism, and sheer genius changed the world. |
| |
| - From the cover of a Steven Levy book |
| |
+-----------------------------------------------+
| |
| And some people thought that I would dislike |
| being called an "arrogant hacker" |
| |
| - Bob Hartman, "Arrogant Hacker II" |
| |
+-----------------------------------------------+
UPFRONT oMMM
------------------------------------------------------------------------------
+---------------------------------------------+
| |
| Technology itself has changed. |
| |
| Not for us the giant steam-snorting wonders |
| of the past: the Hoover Dam, the Empire |
| State Building, the nuclear power plant. |
| |
| Eighties tech sticks to the skin, responds |
| to touch: the personal computer, the Sony |
| Walkman, the portable telephone, the soft |
| contact lens." |
| |
| - Bruce Sterling |
| |
+---------------------------------------------+
The Matrix is an international connection between individual
system operators. Other system operators may be getting
access to this "network" using various pieces of software
including Fido<tm> and Seadog<tm>.
One method for Opus sysops to use the matrix is a program
call oMMM: the Opus Matrix Message Masher.
oMMM creates the `.OUT' and `.FLO' files used by Opus-Cbcs
for outbound matrix traffic.
Actually, it combines the functionality of such programs
as Arcmail[(c)SEA] with the "generating packets" rigmarole
previously internal to programs putting messages onto
the IFNA<tm>-type network.
Opus<no_tm> Outbound (or "OO" for sort) is compatible but not
identical to existing IFNA<tm>-type network software. Please
do not just assume you understand such things as routing just
because you are familiar with other<tm> systems.
This document is a combination How-To on the oMMM program
as well as a technical reference document on Opus outbound
matrix traffic. If you are primarily interested in oMMM,
please have some patience if things get too technical.
For the most part, the target audience of this document
consists of system operators who are already familiar with
the operation of the IFNA<tm>-type network. By the time
you read this, it's possible other documentation will have
been written... documentation that takes the abject novice
into account. What you are currently reading is NOT
such a document. Sorry.
This document does not address the issue of getting a new
system hooked up to the matrix.
OUTBOUND HOLD AREA oMMM
------------------------------------------------------------------------------
+---------------------------------------------+
| |
| I think it might be in the basement - |
| I'll check upstairs. |
| |
| -M.C. Escher |
| |
+---------------------------------------------+
Pending outbound traffic is stored in a special sub-directory
called a HOLD AREA.
To be on the safe side, you should make this sub-directory
just for the holding area. In other words, it is possible
(or likely) that Opus will get confused if it finds other
material in the sub-directory. Opus considers everything in
that area to be "fair game" as far as creating, deleting,
and appending is concerned.
METHODS oMMM
------------------------------------------------------------------------------
+---------------------------------------------+
| |
| Whenever a system becomes completely |
| defined, some damn fool discovers something |
| that either abolishes the system or expands |
| it beyond recognition. |
| |
| - Finagle's Fifth Rule |
| The Book of Rules |
| |
+---------------------------------------------+
Other<tm> programs which do IFNA<tm>-type network mail have
built-in routines which build bundles ( or "generate packets").
These bundles are sometimes built and un-built several times
before they are transmitted.
Opus does not contain any internal bundling routines. You have
to use an external program, such as oMMM. The reason for this
is simple: MEMORY. To do bundling correctly takes vast amounts
of memory, and Opus just does not want to share that much
memory with a bundler.
There is another reason for keeping it external: clever
programmers can write their own bundling programs to handle
whatever special cases might arrise.
The final reason is speed because bundles are built once.
Bundles are kept current. Opus wants to be ready for matrix
traffic at any time. Because of this, there is no facility
provided for un-doing a bundle (ie. separating a bundle into
the individual messages). A special un-bundler utility could
be written for such a thing if anybody is inflicted with
the need.
WHAT'S IN THE HOLDING AREA oMMM
------------------------------------------------------------------------------
You can expect to find three kinds of files being stored
in your holding area:
OUT files ... Normal bundles of messages waiting
to be transmitted. The extension may
actually be OUT, DUT, HUT, or CUT.
FLO files ... A list of files waiting to be transmitted.
This file contains the names of all the
files to be sent as "file attaches" as
well as any archived bundle files built
by the oMMM program. It is a standard,
garden-variety text file with only one
file per line (NO WILDCARDS).
The "#" is a special flag that can appear
as the first character of a line. If
a line begins with a pound sign, the file
listed on that line will be truncated
if it is successfully transmitted. This
is primarily for use with archived bundles.
They need to be "null'ed" after they are
sent.
Flow files can have these extensions: FLO,
DLO, HLO, and CLO.
MO# files ... Most sysops would call these "ARCMAIL"
files. They are bundles of messages which
have been compressed using a program such
as ARCE or ARC (Mail Outbound).
The file extension will be "MO" followed by
a number (0-9). The characters stand for
MATRIX OUTBOUND and do not refer to any
day of the week. oMMM does not produce any
"TU#"..."SU#" files.
NOTE: Opus supports a 12-bit LZ
compression method. Some programs
(eg. PKARC) use a 13-bit method.
They will require far to much
memory to run and should not be
used for archiving mail.
SIMPLE oMMM oMMM
------------------------------------------------------------------------------
+---------------------------------------------+
| |
| The concept is simply staggering - |
| pointless - but staggering!" |
| |
| -The Doctor |
| |
+---------------------------------------------+
The oMMM program words in two phases.
In its simplest form, oMMM will generate an OUT file for
every system which has traffic in your matrix message area.
There is simply no concept of "routing" at this point. If
a system has a message, there will be an OUT file.
This is a "no-route" kind of operation. The OUT files will
eventually be transmitted directly to the destination without
going through any intermediate system such as a "host" or "hub".
Every time you execute it, oMMM goes through this stage.
THE INDIRECT APPROACH oMMM
------------------------------------------------------------------------------
+---------------------------------------------+
| |
| A man's best friend is his dogma. |
| |
| -Anonymous |
| |
+---------------------------------------------+
ROUTING IN A NUTSHELL
---------------------
After all of the bundles have been generated, you can use a
control file to send messages through a "host" or "hub" or
some other intermediate system.
In Opus, all indirect transmissions use archived message files.
We will be creating an archive of routed files. Here is a sample
control file command:
ArcTo 136/12 136/ALL
This command tells oMMM to build an ARC type file for 136/12
and will include the OUT files for any other system in net 136.
TechNote: The "OUT" extension is changed to "PKT" when
the messages are archived.
You can specify several systems in an ArcTo statement:
ArcTo 124/0 130/14 130/20 105/ALL
This command will build an ARC file for 124/0. The file will
contain any existing OUT files for 124/0, 130/14, 130/20 and
all systems in net 105.
FLAVORS OF ROUTING
------------------
"Arcto" is just one of several words you can use to affect
the behavior of outbound matrix traffic.
To hold archived mail for pickup by the other system, substitute
the word "HOLD" for the word "ARCTO". For example...
Hold 141/491 161/ALL
This hold command puts messages for 141/491 and all systems in
net 161 into an archive and marks the whole thing as "hold for
pickup by 141/491".
IMPORTANT: The "hold" statement stands by itself. In other
words, you don't use hold with another command such
as "ArcTo." Instead, "hold" REPLACES the "ArcTo"
statement. It does everything that "ArcTo" does
with the additional feature of marking the resulting
bundle as HOLD FOR PICKUP.
HINT: In the following list, the words ARCTO, HOLD, and
CRASH are considered the basic statements. In most
cases, you can lead a fruitful/meaningful life with
nothing more complicated than those three words.
All of the other words are for advanced usage or
for special circumstances. (K.I.S.S.!)
Here is a list of commands that oMMM understands:
SCHED..... Starts a schedule. All oMMM statements between
this statement and the next SCHED statement will
be executed if the schedule tag matches the one
given on the command line. tag is a character
that can be in upper or lower case.
SYNTAX: Sched tag
ARCTO..... Send as regular mail during pre-set schedules.
This command actually ARC's up the packets just
like ARCmail would do, so you must be sure that
the receiving system either has ARCmail that runs
at regular intervals, or is running Opus 1.00 or
higher.
SYNTAX: Arcto destination [routelist]
EXAMPLES: Arcto 124/0 124/ALL
Arcto 135/1
POLL...... This creates a dummy .OUT file if there are no
files existing for the given node that are not
on hold. If there are files in the holding area
which are going to the given node, and they are
not on hold, then the POLL statement will do
nothing.
SYNTAX: Poll destinations
LEAVE..... Mark all packets to the listed nodes such that
Opus will not attempt to send them. Use the -z
command line option of oMMM to make the packets
be recognized by Opus for future sending. Use
this option with extreme care!
SYNTAX: Leave destinations
SEND...... If a node in the destination list has a packet
that has been marked as a "do not send" packet
by using LEAVE, then make it so that the packet
can once again be sent.
SYNTAX: Send destinations
EXAMPLE to do local schedule with some
extra nodes:
; First mark all nodes as no-send
Leave All
; Now send to our net and list
Send Ournet 132/101 124/108
DOCRASH... If a node in the destination list has a packet
that has been marked as a "do not send" packet
by using LEAVE, and the packet is a crashmail
packet, then that packet is marked for sending.
SYNTAX: DoCrash
HOLD...... Prepare the archive, but disallow an outgoing
phone call. The archive will be held for the
other system to pickup. This has the same comment
as the ARCTO statement - ie the receiver must have
some way to unARC the packets.
SYNTAX: Hold destination [routelist]
ONEHOLD... This call is identical to the above call except
that all nodes listed have the packets held
individually. This allows statements to be used
in a program like XlatList<tm> that will hold for
a list of nodes.
SYNTAX: OneHold destinations
CRASH..... Send to a system which supports continuous
mail. Such systems include other Opus systems
and Seadog (v4.00). Again, the receiver must have
a way to unARC the packets.
In the Opus control file, you have some control
over continuous mail. See the part dealing with
"Matrix send local only".
Note that Opus "crash mail" is compatible but
not identical to so-called crash mail in other<tm>
systems.
SYNTAX: Crash destination [routelist]
ONECRASH.. This call is identical to the above call except
that all nodes listed have the packets crashed
individually. This allows statements to be used
in a program like XlatList<tm> that will crash to
a list of nodes.
SYNTAX: OneCrash destinations
UNCRASH... Any packets to the nodes in the list that are
marked as CRASH are marked normal.
SYNTAX: UnCrash destinations
UNHOLD.... Any packets to the nodes in the list that are
marked as HOLD are marked normal.
SYNTAX: UnHold destinations
NORMCRASH. Any packets to the nodes in the list are sent
as CRASH type packets that are compatible with
other <tm> software. This basically means that
the packet is not ARC'd.
SYNTAX: NormCrash destinations
NORMHOLD.. Any packets to the nodes in the list are sent
as HOLD type packets that are compatible with
other <tm> software. This basically means that
the packet is not ARC'd.
SYNTAX: NormHold destinations
THE CONTROL FILE oMMM
------------------------------------------------------------------------------
+---------------------------------------------+
| |
| There are two kinds of people in the world: |
| Those with loaded guns, and those who dig. |
| You Dig. |
| |
| - Clint Eastwood |
| 'The Good, The Bad, and The Ugly' |
| |
+---------------------------------------------+
CONTENTS OF A CONTROL FILE
--------------------------
The oMMM control file is a text file.
You can use a semi-colon (";") as a comment character.
oMMM will ignore everything beyond a semi-colon on a line.
Put the word ARCTO in the far left column. That's followed
by the destination board plus 0 or more other systems.
Examples:
arcto 161/2 ; just archive 162/2's stuff
arcto 100/0 100/ALL ; "host route" net 100
DO WHAT I SAY, WHEN I SAY IT
----------------------------
You should consider the control file as a PROCEDURAL file.
In other words, oMMM will act on every statement as it comes
to it. The control file is a list which says "Do this, then do
that, then do whatever." Here's an example of how you can use
this kind of operation:
arcto 130/12 130/20
arcto 130/0 130/ALL
There. Material for 130/20 and 130/12 will go to 130/12. Then
everything else to net 130 will be "host routed". The first
statement takes care of 130/12 and 130/20. By the time oMMM gets
to the second line, material for those two systems no longer
exist as individual OUT files.
SPECIAL WORDS
-------------
In addition to "ALL" as a special "node number", the words "OTHERS",
and "OURNET" can be used as special "net numbers". They mean
networks other than our own and your own network respectively. If
your net has an outbound system ("Host" or "Hub") then you can route
out-of-town traffic to that system like this:
arcto 124/0 OTHERS
The command with "others" in it should probably be one of the
last commands in your control file. Remember, this is a
procedural file. Take care of your specific routing, then do
the "others" command as a kind of "clean up" command.
NOTE: If you are using XlatList<tm> to create your oMMM control file
you will find that it will not pass the keyword ALL through
to the control file when it is used on an ArcTo line (or any
other line with other node numbers). In this instance, you
should use the keyword WORLD which has the same meaning as
the keyword ALL.
USING oMMM oMMM
------------------------------------------------------------------------------
+---------------------------------------------+
| |
| No matter what you do today, nor where you |
| go, nor whom you meet, there are at least a |
| billion red Chinese who don't give a damn. |
| |
| - Dan Jenkins |
| |
+---------------------------------------------+
OPERATIONAL OVERVIEW
--------------------
You must have the program ARCA.COM available somewhere
on your path.
The oMMM program needs seven pieces of information from you.
SWITCHES ... the optional switches that can be on the
oMMM command line. The available switches
are:
-d to disable the conversion of Opus dates
back to older Fido<tm> dates. This should
not be used unless all connections are
made with other Opus nodes.
-z to ZAP the entire holding area so that
all packets that the LEAVE statement had
to modify are returned to normal.
-n to disallow forwarding of messages for
other boards. Note that you cannot use
this switch if you are a host or hub!
-------------------------------------------
SCHEDULE TAG ... the character corresponding to the schedule
which oMMM should use in the control file.
To specify the schedule tag, use '-s'
followed by the character for the TAG.
If you don't specify a schedule tag, oMMM
will assume no schedule and process any
statements in the control file that are
before the first SCHED statement.
-------------------------------------------
INFO PATH ... the sub-directory that contains the
file MAIL.SYS.
To specify the info path, use '-i'
followed by the name of the sub-directory.
If you don't specify an info path, oMMM
will use the current default sub-directory.
-------------------------------------------
HOLD PATH ... the sub-directory used as the Opus
outbound hold area ("OO-HA" for short).
To specify the hold path, use '-h'
followed by the name of the sub-directory.
If you don't specify a hold path, oMMM
will complain at you loudly and will
refuse to continue. (Dos ERRORLEVEL=1)
-------------------------------------------
MESSAGE PATH ... the sub-directory where your matrix
messages are kept.
You only need to use this item if you
are doing something "non-standard". If
you are taking messages from your normal
matrix message area, do not declare
any message path.
To specify the message path, use '-m'
followed by the name of the sub-directory.
If you don't specify a message path,
oMMM will use the path declared in
the info file, MAIL.SYS.
-------------------------------------------
PRE-MESSAGE SCAN
CONTROL FILE ... the name of the file containing routing
commands to be executed BEFORE message
scanning takes place!
To specify the pre-message scan control
file name, use '-p' followed by the name
of the control file.
If you don't specify a pre message scan
control file, no changes will be made to
the holding area before messages get
scanned.
This command is useful for systems that
do a lot of 'state changes' during the
day. For example, a system may want to
Hold mail in an archive for a node at
some times, and send it at other times. In
this scenario it is very possible that
oMMM could create a file attach message,
then have that archive placed into the
actual archive when oMMM was run again.
This is undesirable behavior which can
be overcome using a pre-control file. For
example, you have just executed a Hold
statement for a node which places a file
attach message in a .HUT file. Now you
decide to send to that node by using the
UnHold verb, that places the file attach
message in a .OUT file. Finally, the
archive was not sent out, so you once
again want to hold for the node, normally
you would use Hold to do this, but that
will packet up the file attach message
that is still in the .OUT file. The
solution is to use a pre-scan control file
to NormHold the node, then in the normal
routing file use Hold to archive the new
messages (the .HUT will still contain the
file attach message and it will not be
archived), and after the Hold is executed,
an UnHold can be executed if necessary.
This sounds a lot more complex than it is.
Simply use a pre-scan control file to get
your holding area into the same state all
the time before the real routing gets done.
This will save hours of time trying to
determine what oMMM will do under certain
conditions. Eventually this may also be
used to force oMMM to un-oMMM packets.
-------------------------------------------
CONTROL FILE ... the name of the file containing routing
commands.
To specify the control file name, use '-c'
followed by the name of the routing
control file.
If you don't specify a routing control
file, no routing will be done.
Example:
oMMM -hc:\opus\outbound
oMMM -hc:\ob -cc:\routes.ctl
One final note about using oMMM. It may sometimes seem like
a slow-running program. I can promise you that it is not.
Internally, it is screaming out instructions to your computer
as fast as possible. Remember: oMMM combines the functionality
of an "arcmail" program with the "generating packet" of other<tm>
matrix systems. With oMMM, you only have to generate those
bundles once... when the archives are built.
REFERENCE STUFF: FILE NAMES oMMM
------------------------------------------------------------------------------
+---------------------------------------------+
| |
| "You bring the light, |
| 'n' I'll bring the tunnel." |
| |
| - H. Nehgila |
| |
+---------------------------------------------+
TECHIE ALERT
------------
This section is for reference... for the technical and/or
intensely curious.
FILE NAMES: Nodes
-----------------
File nodes (the file name without the extension) are made
from the destination's net and node. Each part of the matrix
address is converted to a four-digit hex (base 16) number.
For example, an OUT file to 124/108 would be "007C006C.OUT".
Net 124 is "007C" in base 16. The node 108 is "006C" when
done in hex.
FILE NAMES: Extensions
----------------------
File extensions on Hold Area files have a meaning to Opus.
.OUT ... a regular TYPE-2 outbound bundle
.CUT ... an TYPE-2 bundle containing CRASH messages
.HUT ... an TYPE-2 bundle on hold. Opus will not try
to call this system, but will make it available
should the other system call.
.DUT ... internally generated unrouted bundle. (D="direct")
.FLO ... a regular flow file
.CLO ... a flow file for CRASH delivery
.HLO ... a flow file being held for pickup
There is nothing in Opus to prevent you from using a text
editor to create a FLO outbound file.
It is *NOT* necessary for you to create a "file attach message".
Opus will automatically generate a "dummy empty bundle" during
the actual connection to simulate the attach message.
FILE NAMES: archives
--------------------
Using the routing system of oMMM, you will end up with archives
created by the program ARCA. The names are a little peculiar.
They are generated by taking the difference between the sender's
and the receiver's matrix address.
For example, if 136/1986 were to send mail to 105/6, the archive
file name would work like this:
136 - 105 = 31 ..... 001F
1986- 6 = 1980 ..... 07BC
Filename ............... 001F07BC.MO1
If 105/6 has something to say back to 136/1986, here's how
the file name would be calculated:
105 - 136 = -31 ..... FFE1
6 - 1986 = -1980 ..... F844
Filename ............... FFE1F844.MO2
The use of this method is an attempt to stay compatible with
existing IFNA<tm>-type network message archive programs.
The extensions ("MO1" and "MO2") are almost meaningless. The
first to characters stand for ARCHIVED MESSAGES. The digit
is a counter. When oMMM sees that Opus has delivered a
previous archive such as "MO1", it will increment the next
archive to "MO2" to help avoid over-writes on the receiving
system. The numbers go from 1 to 9 then start at 1 again.
When oMMM is used to put bundles into an archive, it generates
a dummy message in a bundle with ".DUT" for the extension.
To: "SysOp"
From: "OPUS Matrix Message Masher"
It also generates (or appends) a FLO file for the file attachment.
WHAT ABOUT OPUS? oMMM
------------------------------------------------------------------------------
Opus will try to send material (not marked ".HLO" or ".HUT").
In other words, it assumes that you and your bundle program
know what you want.
Currently there is no concept of a "schedule" in Opus. It will
try to dial numbers when it feels like dialing.
Also, there is no concept of a system that is unable to do
continuous mail. Fido<tm> systems, for example, are completely
unable to receive mail except during a schedule. Old Seadog<tm>
systems are not able to hold bundles and files for pickup
except during a scheduled network event.
There is definitely a need for a program that can use the
"raw" nodelist information ("NODELIST.###" file) to produce
a routing control file to assure that material headed for
older systems is marked HOLD. Otherwise, Opus will try to
call those systems.
Here's the Real Bummer: the oMMM program knows diddley-squat
about such nodelist flags as "#CM:". oMMM will not put anything
on hold.
In the Opus control file, you can declare such things as your
matrix hold area. There are flags that say SEND NOTHING (make
no outgoing calls) and LOCAL ONLY (make calls only to those
systems whose "cost" field is zero).
The main point is that Opus considers the hold area current.
CYBERPUNK? oMMM
------------------------------------------------------------------------------
+---------------------------------------------+
| |
| Cyberpunk comes from the realm where the |
| computer hacker and the rocker overlap, a |
| cultural Petri dish where writhing gene |
| lines splice. Some find the results bizarre,|
| even monstrous; for others this integration |
| is a powerful source of hope. |
| |
| - Bruce Sterling |
| |
+---------------------------------------------+
This has nothing to do with oMMM, but because I called The
Matrix "the world's first CyberPunk BBS Network" I'd better
explain the term.
CyberPunk is a kind of science fiction.
Characters in such works have been described in several
ways. Here are a couple:
* Low-budget high tech
* Miami Vice with lasers
* Ray-gun gothic
The street people in such books are normally the techies.
It can conjure up images of that broken-down freighter in
the original Star Wars if you aren't careful.
The TV show MAX HEADROOM is CyberPunk.
One repeating theme is this: surrounded by computers and
equiped with the knowledge of how to use them, CyperPunk
characters often struggle to maintain a sense of humanity.
If there is to be any kind of struggle, that particular
one sounds more worthy of my time than others.
Finally, a short conversation from Gibson's "Johnny
"Mnemonic"...
"Who's Lo Tek?"
"Not us, boss."
Lo Tek is just a gang in the book, of course. But it's
a term you may run across from time to time when you hook
into The Matrix: The World's First CyberPunk BBS Network.
Wynn
###
